Various forms of data storage systems exist today. Network-based storage systems typically include at least one storage server, which is a processing system configured to store and retrieve data on behalf of one or more client processing systems (clients). The data is stored and retrieved as storage objects, such as blocks and/or files. A block is a sequence of bytes or bits of data having a predetermined length. A file is a collection of related bytes or bits having an arbitrary length. In the context of network-attached storage (NAS), a data storage system operates on behalf of one or more clients to store and manage file-level access to data. The files may be stored in a storage system that includes one or more arrays of mass storage devices, such as magnetic or optical disks or tapes, or solid state devices such as flash, by using a data storage scheme such as Redundant Array of Inexpensive Disks (RAID). In a SAN context, a storage server provides clients with block-level access to stored data, rather than file-level access. Some storage servers are capable of providing clients with both file-level access and block-level access, such as certain storage servers made by NetApp, Inc. (NetApp®) of Sunnyvale, Calif.
Write Anywhere File Layout (WAFL) data storage systems, including a WAFL aggregate, may include one or more flexible volumes, one or more volume containers, and physical storage. A WAFL aggregate is a physical storage container that can store data in the WAFL file system. A flexible volume is a logical volume that allows the virtualization of the allocation of volumes on physical storage. Thereby multiple, independently managed flexible volumes can share the same physical storage (e.g., physical storage). The virtualization requires mapping between virtual volume block numbers (VVBNs) used by flexible volume and physical volume block numbers (PVBNs) used by a WAFL aggregate to access data stored in physical storage. A PVBN, as used herein, refers to disk blocks that have been abstracted into a single linear sequence in the aggregate. Each volume container corresponds to a flexible volume. A volume container contains all the data blocks for a corresponding flexible volume.
As used herein, a block offset or an offset refers to a distance from the beginning of a storage object such as a volume, file, extent, etc. Block addresses used within a flexible volume refer to block offsets within a volume container. Since a volume container contains every block within a flexible volume, there are two ways to refer to the location of a particular block. The PVBN specifies the location of a block within a WAFL aggregate.
The VVBN specifies the offset of the block within the container file. When a block in a file is requested, a flexible volume translates the file offset into a VVBN. The VVBN is passed from a flexible volume to a volume container. A volume container translates the VVBN to a PVBN. The PVBN is then used to access the requested block in physical storage.
Additionally, when a PVBN is initially written, the block pointer for the PVBN in a flexible volume is written to include (e.g., in a cache) the PVBN for the VVBN. Thereby, when the requested block is required, the flexible volume can use the stored PVBN to access physical storage.
Current implementations of WAFL define a file as a component of a hierarchical organization of data such as a tree of indirect blocks. Each indirect block in the tree has a predetermined span size: a predetermined number of entries, each pointing to another block in the tree. Extents are represented using an entry for each block within the extent. An extent, as used herein, refers to a contiguous group of one or more blocks. As a result, the amount of indirect block metadata is linear with respect to the size of the file. Additionally, disk gardening techniques, such as segment cleaning, file reallocation, etc., are complicated by caching PVBN pointers in VVBN blocks.
Storage systems often use a predetermined block size for all internal operations. For example, WAFL uses 4 KB (e.g., 5096 bytes) blocks for both VVBN and PVBN, as do client-side file systems for file block numbers (FBN). Block boundaries are expected to occur every 4 KB from an initial offset (e.g., FBN 0). Since file systems usually offset individual files based on these block boundaries, application writers take advantage of a file system's block size and alignment to increase the performance of their input/output (“I/O”) operations—for example, always performing operations that are a multiple of 4 KB, and always aligning these operations to the beginning of a file. Other file systems or applications, such as a virtual machine, may use a block boundary of a different size (e.g., a virtual machine environment in which an initial master boot record block of 612 bytes is followed by the expected 4 KB blocks), resulting in misalignment between FBNs and PVBNs. Additionally, multiple virtual machines may share a single volume container and each virtual machine may be misaligned by a different amount.
Consequently, it would be advantageous if a method and apparatus existed that are suitable for executing partial write operations and misaligned write operations as if they were full, properly aligned write operations for later correction when system resources are available. Such a method and apparatus would be particularly advantageous in a data storage system utilizing data compression.